昨天那份 5 MB 的檔案,已經是完整而且可以追溯的了。
但它沒有辦法直接拿去用,原因很簡單:太大。
Day 16 那條規則說了,不能全讀。所以要能「需要時再查」,就得先把它切成一塊一塊、可以單獨被撈出來引用的東西。
這件事聽起來像一個調參數的工作:切多大? 太大會塞爆、太小會失去脈絡,那就試幾次找一個中間值。
我一開始也是這樣想的。而那個想法錯在更前面一步。
最直覺的作法是:一張票卡 = 一塊。
這個作法有很多好處。邊界清楚、天然帶著來源、要追回去很容易。
所以我原本以為接下來的工作,是在「一張卡一塊」和「一張卡切成好幾塊」之間找一個平衡點——調幾次,看哪個撈得比較準。
但我試了之後發現,那個實驗做不下去。
因為要調整顆粒大小,前提是原本的單位是一致的。你得先有一個穩定的尺,才能討論要放大還是縮小。
而票卡不是。
我把幾張卡攤開來並排,才看清楚這件事有多麻煩。
有一張卡,它只有一句話。 標題寫完,描述一行,沒有留言。它講的就是一件事,改完就關掉。
另一張卡,裡面有五個決定。 需求原本是 A,討論之後改成 B,做到一半發現 C 不可行,於是又退回來,最後還順手處理了一個沒人提過的例外。這些全部在同一張卡的留言區裡,依時間順序疊著。
這兩張,在系統裡是同一個東西——一張卡。
但它們裝的內容,差了五倍不只。
所以「一張卡一塊」這個作法,實際上會產出這樣的結果:
有些塊裡面只有一句話,撈出來什麼脈絡都沒有。
有些塊裡面有五件事,撈出來的時候,你要的那一件被另外四件蓋住了。
第二種特別糟,而且它糟的方式很眼熟——那正是 Day 16 講的「餵太多它會變笨」的縮小版。 我以為我在餵一塊相關的資料,實際上我餵了四份雜訊加一份答案。
再往下追一層,問題就更清楚了。
票卡的大小,取決於誰開的。
Day 2 我寫過兩張性質完全不同的卡:
這兩種人開出來的卡,結構根本不一樣。一個把所有東西寫進留言,一個把所有東西寫進描述;一個一張卡追蹤一整條線,一個一張卡對應一個修改點。
而更麻煩的是,還有 AI 開的卡——那批的密度又是另一種樣子。
所以「一張卡有多大」這個問題,真正的答案是:
它取決於開卡的那個人的習慣,而那件事我完全控制不了。
我在資料裡看到的不一致,不是資料的問題,是組織的問題——每個人記錄事情的方式本來就不一樣,而且沒有人規定過要一樣。
(而且我也不認為應該規定。一個很有幫助的留言,不該因為「格式不符」被要求重寫。)
想通這件事之後,方向就變了。
問題不是「一張卡要切成幾塊」,而是:
票卡這個單位,本來就不該拿來當單位。
它是一個行政單位——為了追蹤工作進度而存在的容器。它的邊界是「這件事誰負責、做完了沒有」,而不是「這裡面有幾件事實」。
我要的是一個語意單位。
而後來收斂到的答案是:
一則決策 = 一塊。
一張卡上如果有五個決定,它就變成五塊。如果只有一句話,那就是一塊。
這樣切出來的東西,每一塊都是自己完整的:它講一件事,有前因,有結論。撈出來的時候不會缺一半,也不會夾帶四件無關的事。
我不想把這件事講得太順,因為它有兩個實際的成本。
第一,「一則決策」的邊界要靠判斷。
「一張卡」是機器就數得出來的。「一則決策」不是——你得讀懂那段留言在講什麼,才知道它是一個新的決定,還是前一個決定的補充。
而這個判斷一旦交出去,就有可能切錯。切錯的後果跟 Day 9 一模一樣:一個真的零件,被放到錯的塊裡面。
第二,追溯的鏈變長了。
原本一塊就是一張卡,sourceRaw 指回去很直接。現在一塊是一張卡的一部分,所以每一塊都得額外記住:我是從哪一張卡、哪一則留言、第幾段來的。
這也是為什麼昨天那份結構裡,留言要完整保留、帶日期帶作者——不是為了存檔,是因為切塊的時候需要那些座標。
當時多留的東西,後來變成了切得下去的前提。
這整件事對我來說,最有價值的不是最後選了哪個顆粒大小。
是我意識到:
我原本以為我在調一個參數,其實我在選一個單位。
這兩件事的差別很大。調參數是在一條連續的軸上找一個點——你可以試、可以比較、可以慢慢逼近。
而選單位是一個分類問題:你在決定「什麼東西算是一件事」。
而在一個資料是由很多人、用很多種習慣、在很長一段時間裡累積出來的地方,「什麼算一件事」這個問題,原始資料是不會回答你的。
它只會告訴你:這裡有 1,183 個容器。
至於每個容器裡裝了幾件事——那得自己判斷。
今天講了怎麼切。而一個很自然的問題是:
切得對不對,誰來檢查?
Day 7 到 Day 11 那幾篇的結論是:AI 產出的東西要被驗證。而現在這份知識庫本身就是 AI 幫忙產出的——那它當然也要被驗。
明天講知識庫自己的測試,包括我想加但還沒做的那幾項。
iThome鐵人賽
看影片追技術